method for sharing functionality and/or data between two or more linked entities

ABSTRACT

A method for sharing functionality and/or data between two or more linked entities using a network. The method comprising the steps of creating on at least one entity at least one real object, each real object providing access to the functionality and/or data of the entity. The method further comprising the step of creating on each entity at least one virtual object, each virtual object providing access to the functionality and/or data of a real object on the entity, each virtual object containing at least one object action. The method further comprising the step of creating on at least one entity at least one remote object for connection to a virtual object on a remote entity via the network; the remote object allowing an entity to access functionality and/or data of a remote entity.

TECHNICAL FIELD

The invention concerns a method of sharing data, between a number ofcomputers, or with other electronic devices, such as mobile telephones,personal digital assistants (PDAs), or the like. The data is shared viaan electronic connection between these devices, especially via theinternet, or via other means such as a LAN, WAN or wireless network, forinstance. In particular, the invention concerns the sharing of datastored on separate devices, in a secure manner, optionally usingencryption, over the internet using a special secure partition. Theinvention relates to the secure partition, a method of creating a securepartition and application software to perform the method of creating asecure partition. The invention also concerns a computer system, methodand interface to provide access to data and functionality contained inone or more remote devices.

BACKGROUND ART

Many people use multiple digital devices that store information. Forexample, a user might use a smart mobile phone, a laptop at home and apersonal computer at work. Traditionally, this has been difficult to do,because the data must be manually transferred from one device toanother. There are other means available of synchronising the databetween two or more devices, but these generally require a specificsoftware application to do this.

There is an increasing need to be able to access the information storedon these devices securely from anywhere. This should be simple tooperate and manage, and allow any type of data, and the softwareapplication that accesses and modifies each type of data to be availableon any of a user's electronic devices. The data is accessed via anetwork, such as the internet, or WAN, for instance, and the datasharing system should also have effective security to allow only theowner of the data to access it, from whatever device they are currentlyusing.

Various systems and method have been devised in an attempt to linkmultiple devices. For example GB2411092 to Changwen et al describes thecreation of a secure network path for a mobile node e.g. laptop. Themethod involves sending a registration request to a home agentspecifying permanent network address for mobile node and proxy care-ofaddress. The proxy care-of address is used for communicating with themobile node.

Another example is WO04081818 to Fontijn et al that describes a methodof transferring ownership change among devices in a peer-to-peernetwork. The method invokes propagating change to one or more devicesfor which change is relevant. The responsibility of committing thechange is passed among the devices.

The term “comprising” as used in this specification means “consisting atleast in part of”. When interpreting each statement in thisspecification that includes the term “comprising”, features other thanthat or those prefaced by the term may also be present. Related termssuch as “comprise” and “comprises” are to be interpreted in the samemanner.

As used herein the term “and/or” means “and” or “or”, or both.

As used herein “(s)” following a noun means the plural and/or singularforms of the noun.

It is intended that reference to a range of numbers disclosed herein(for example, 1 to 10) also incorporates reference to all rationalnumbers within that range (for example, 1, 1.1, 2, 3, 3.9, 4, 5, 6, 6.5,7, 8, 9 and 10) and also any range of rational numbers within that range(for example, 2 to 8, 1.5 to 5.5 and 3.1 to 4.7).

The entire disclosures of all applications, patents and publications,cited above and below, if any, are hereby incorporated by reference.

In this specification, where reference has been made to external sourcesof information, including patent specifications and other documents,this is generally for the purpose of providing a context for discussingthe features of the present invention. Unless stated otherwise,reference to such sources of information is not to be construed, in anyjurisdiction, as an admission that such sources of information are priorart or form part of the common general knowledge in the art.

DISCLOSURE OF THE INVENTION

The present invention is now described in general terms. It is an objectof the present invention to provide an improved private network or atleast to provide the public or industry with a useful choice.

In a first aspect the present invention consists in a method for forminga secure virtual private network (VPN) consisting of two or more linkedentities having internet connectability where each entity has links withat least one other device on the VPN, said method comprising the stepsof:

(a) providing a lookup device having a known address with an updatableindex of entities known to be connectable to the VPN, which look updevice accepts requests from known entities (“joining entity”) wishingto link to the VPN,

(b) causing at least one pre-designated contact entity on the VPN toperiodically poll the lookup device for received joining requests,

(c) said lookup device receiving a request from a joining entity toconnect to the VPN

(d) in response a poll for joining requests said lookup device notifyingthe polling contact entity of at least the address of each joiningentity;

(e) if the contact entity permits a connection to the VPN, the contactentity supplies at least its address to the lookup device which passesthis to the joining entity,

(f) the joining entity and contact entity establish a first link betweenthem,

(g) the joining entity and the contact entity conduct an authenticationprocess over said first link,

(h) and if the authentication process is successful the contact entitynotifies the joining entity of at least the status of other entitiesbelonging to the VPN and notifies all entities on the VPN that thejoining device is joining the VPN,

(i) said joining device using the status of other entities belonging tothe VPN to calculate its node position in the VPN including the one ortwo neighbour entities it will connect to,

(j) said one or two neighbour entities initiating a process of the typespecified in steps (c) to (f) with said lookup entity to establish oneor more second links with said joining entity and terminating said firstlink,

(k) and said joining entity and at least one neighbour entity conductinga mutual authentication process which if successful sustains said one ormore second links.

Preferably said method including an initial registration step wherebyentities register with the lookup device for access to one or moredesired VPNs and only entities which are so registered are subsequentlyrecognised or known to the lookup device, said registration stepcomprising: the entity sending to the lookup device registrationinformation including at least a username, a password, and the lookupdevice storing said registration information for identification purposeswhen a registered entity sends a VPN joining request to the lookupdevice.

Preferably said registration step includes the lookup device sending toregistering entities a security key to allow such entities to accesssecurity keys unique to VPN for which registration has been made and theother entities registered for that VPN.

Preferably in step (h) the contact entity further notifies the joiningentity of the entity identifiers of other entities belonging to the VPN.

Preferably in step (i) said joining entity additionally uses the entityidentifiers of other entities belonging to the VPN to calculate its nodeposition.

Preferably said entity identifier is an address.

Preferably said authentication process consists of each of the twoentities challenging the other using a key unique to the purportedidentity of the other entity, each challenge comprising a transmissionto the other entity, a response from the other entity and verificationby the challenging entity that the response is correct.

Preferably each challenge between a first entity and a second entitycomprises the steps of:

(a) the first entity generates a random sequence of data, stores it andencrypts it with the public key of the second entity and sends theresultant cyphertext to the second entity,

(b) the second entity receives the cyphertext from the first entity,decrypts it using the private key of the second entity, encrypts theresultant plaintext with the public key of the first entity and sends itto the first entity, and

(c) the first entity receives the cyphertext from the second entity,decrypts it using the private key of the first entity compares theresultant plaintext with said stored random sequence of data and ifthere is a match accepts that the second entity is authenticated.

Preferably data traffic between entities connected to a VPN is encryptedusing a symmetric key and said symmetric key is said random sequence ofdata.

Preferably said authentication process is periodically repeated and theperiodically generated random data sequences are used as a dynamicsymmetric session key.

Preferably said entities are devices having a processor that can beconnected to the internet.

Preferably said devices include computers, PDAs, PPC, mobile telephonesor smartphones, and embedded devices.

In a further aspect the invention consists in computer software forforming a secure virtual private network (VPN) consisting of two or morelinked entities having internet connectability where each entity haslinks with at least one other entity on the VPN and a lookup deviceconnected to the internet having a known address with an updatable indexof entities known to be connectable to the VPN, said software residingon each said entity and comprising:

(a) a routine for connecting to said lookup device and making a requestto said lookup device to join to the VPN,

(b) a routine for polling the lookup device for received joiningrequests,

(c) a routine for receiving from the lookup device at least the addressof each joining entity,

(d) a routine for matching the address of each joining entity withstored criteria,

(e) a routine which allows matched entities to establish a first linkbetween them,

(f) in authentication routine which enables entities which haveestablished a first link to mutually authenticate the identity of theother,

(g) a routine which if the authentication process is successful notifiesthe joining entity of at least the status of other entities belonging tothe VPN and notifies all entities on the VPN that the joining device isjoining the VPN,

(h) a routine which uses the status of other entities belonging to theVPN to calculate the node position in the VPN and the one or twoneighbour entities that the entity on which the routine resides willconnect to,

(i) a routine which through said lookup device establishes one or moresecond links with said one or more neighbouring entities in said VPN andends said first link,

(j) a routine which invokes said authentication routine to conductmutual authentication between said linked neighbouring entities andwhich if successful sustains said one or more second links.

In a further aspect the invention consists in a method for sharingfunctionally and/or data between two or more linked entities using anetwork comprising the steps of:

(a) creating on at least one entity at least one real object, each saidreal object providing access to the functionality and/or data of saidentity;

(b) creating on each entity at least one virtual object, each saidvirtual object providing access to the functionality and/or data of areal object on said entity, each said virtual object containing at leastone object actions; and

(c) creating on at least one entity at least one remote object forconnection to a virtual object on a remote entity via the network; saidremote object allowing a entity to access functionality and/or data of aremote entity.

Preferably including the step of:

(d) creating on at least one entity a metaobject, said metaobjectproviding access to the functionality and/or data of a plurality ofvirtual, remote and meta objects.

Preferably said metaobject can contain data and/or functionalityindependent of any virtual or remote objects.

Preferably a list of the objects of each entity is synchronized betweenentities.

Preferably each of said virtual and meta objects may include securityfunctionality for controlling access to the object.

Preferably said network is a virtual private network (VPN).

Preferably each of said real objects are selected from the groupconsisting of File Browser, Mail Browser; Calendar Browser; MusicStreamer; Voice module; Video Streamer; Chat module; MediaPlayer Remote;Remote Application Module; Advertisement Module; Banking Module; PrinterModule; Panic Module; Web RSS feed module; FTP Server module; BLOGupdate module; Legacy module; Database module; Web camera module.

Preferably at least one of said entities is a device having a processorand that can be connected to the internet.

Preferably at least one said device includes computers, PDAs, PPC,mobile telephones or smartphones, and embedded devices.

In a further aspect the invention consists in computer software forsharing functionality and/or data between two or more linked entitiesusing a network, said software residing on each said entity andcomprising:

(a) a routine for creating at least one real object, each said realobject providing access to the functionality and/or data of said entity;

(b) a routine for creating at least one virtual object, each of said ofvirtual objects providing access to the functionality and/or data of areal object on said entity, each said virtual object containing at leastone object action; and

(c) a routine for creating at least one remote object for connection toa virtual object on a remote entity via the network; said remote objectallowing an entity to access functionality and/or data of a remoteentity.

In a further aspect the invention provides a secure internet partitioncomprising: two or more devices each containing data and a private keyused for verification checks; wherein, in use of the partition, eachdevice is associated with one or more neighbour device(s); wherein, inuse of the partition, each device also contains a cryptographic key usedfor encryption and/or decryption of data traffic between neighbourdevice(s), and public keys of its neighbour device(s); and wherein inuse of the partition, each device operates to perform a verificationcheck of its neighbour device(s) using its private key and public keysof its neighbours and if a neighbour device is verified, transmittingdata to the neighbour device using the cryptographic key.

The neighbourhood of devices may form a loop. Where the secure internetpartition is comprised of three or more devices, each device may havetwo neighbour devices.

Verification checks may be based on a challenge and responseauthentication. The verification checks may be performed at intervals.The verification checks may be based on a verification sequence that isupdated at intervals.

The cryptographic key may be a symmetrical key and each device may havesubstantially the same cryptographic key.

The partition may further have a lookup point that maintains a list ofdevices that comprise the partition. A further device may join thepartition by obtaining from the look up point address details of adevice in the partition that will be the further device's neighbour.

A device of the partition may be comprised of a set of devices, whereinthe set of devices form a further partition.

The invention also concerns a method of creating a secure internetpartition. In a further aspect the invention is application softwareinstalled on a device, to perform the method of creating a secureinternet partition. In yet a further aspect, the invention concerns alookup point to facilitate a further device to join a secure internetpartition.

In a further aspect the invention provides a secure internet partitionto transmit data securely on the internet, the partition comprising: afirst device containing data to be transmitted to a second device, acryptographic key and a verification sequence; a second devicecontaining the verification sequence received from the first device inorder to verify the second device and the cryptographic key; andwherein, in use of the partition, the first device operates to encryptthe data using its verification sequence and cryptographic key and thesecond device decrypts the data using its cryptographic key andverification sequence.

The first device may operate to encrypt the data using the cryptographickey by combining the cryptographic key with a partition sequence, andencrypting the data using the combined cryptographic key and partitionsequence. The data may be packetized into packets and the combinedcryptographic key and partition sequence is used to encrypt part of thepacket. The packet may comprise a header and body and the part encryptedmay be the body.

The first device may operate to encrypt the data using the verificationsequence by encrypting the partition sequence with the verificationsequence and adding it to the data transmitted to the second device. Thedata may be packetized into packets having a header and a body, and theencrypted partition sequence may be added to the header.

The second device may decrypt the data using its verification sequenceby using the verification sequence to determine the partition sequence.Further, the second device decrypts the data using its cryptographic keyby combining the determined partition with the cryptographic key andusing it to decrypt the data.

The partition sequence may be dynamic in that it is changed atintervals. The partition sequence may be randomly generated. Theverification sequence may be dynamic in that it is changed at intervals.The partition sequence may be randomly generated.

The verification sequence may be unique to the first and second device.The verification sequence may be unique to data transmissions from thefirst device to the second device. The verification sequence may bereceived from the first device as part of a challenge/responseauthentication. The second device may contain a further verificationsequence, and the first device may contain the further verificationsequence that is received from the second device in order to verify thefirst device.

The partition may comprise further devices that all contain thecryptographic key. The partition may comprise further devices and thepartition sequence is used by the first device when transmitting data toany device of the partition.

In a further aspect the invention concerns a method of transmitting datasecurely on the internet. In yet a further aspect the invention concernsa method of receiving data securely on the internet. In another aspect,the invention concerns a software application to perform the methods oftransmitting and receiving data securely on the internet.

In a further aspect the invention provides a computer network to provideaccess to data aid functionality contained in one or more remotedevices, the computer system comprising: two or more devices eachcontaining a real object that allows access to data and providesfunctionality; and wherein, in use, each device is able to access dataand functionality in a remote device by use of a pair of virtualobjects, a first virtual object is positioned in the device forcommunication with the real object, and a second virtual object ispositioned in the remote device for communication with the first virtualobject.

The virtual object may extract data and functionality from the realobject so as to make the data and functionality independent of operatingsystem of the real object. An object may be a software application thatcan store data and provide functionality in the manipulation of thedata.

In use, each device is able to access further functionality in a remotedevice by use of a pair of meta objects, a first meta object may bepositioned in the device for communication with the virtual objectwherein the meta object provides further functionality, and a secondmeta object is positioned in the remote device for communication withthe first virtual object to provide the further functionality with thefirst virtual object. An object may contain multiple actions.

In yet a further aspect the invention provides access to data andfunctionality contained in one or more remote devices. In another aspectthe invention provides an interface for an electronic device, so as toprovide access to data and functionality contained on one or more remotedevices.

Embodiments of the invention provide a secure, flexible and simple wayfor people to access data content stored on a network of multipledevices on a single interface. The user of each device may be differentallow a user of a device to control what content on their device otherscan access using the single interface.

The data can be any digital file such as documents, music, pictures,e-mails, alerts, and updates. Further the data accessed could be fromdynamic sources such a digital input card reading temperatures, or ascreen shot from the device. Any device that is able to be connected tothe network, such as the internet, may be used in conjunction with theinvention.

As used herein, the term “internet” should be interpreted broadly, toinclude other types of networks that connect together electronic devicessuch as computers, mobile telephones, PDAs, and the like, and the term“internet” will include other electronic communication networks, such asintranets, or WAN, LANs, wireless networks etc.

BRIEF DESCRIPTION OF DRAWINGS

Examples of the invention will now be described with reference to theaccompanying drawings, in which:

FIG. 1 shows a schematic view of the architecture of a single cloud;

FIG. 2 shows a schematic view of the architecture of multiple clouds;

FIG. 3 shows a schematic view of multiple entities that are centrallymanaged;

FIG. 4 shows a schematic view of multiple entities that are privatelymanaged;

FIG. 5 schematically shows the relationship between devices andentities;

FIG. 6 shows how objects work to create a single view of data andfunctionality that can be created across multiple devices;

FIG. 7 schematically shows that relationship between real, virtual,remote and meta objects;

FIG. 8 schematically shows the relationship between actions and objects;

FIG. 9 schematically shows how instances of actions are created inobjects;

FIG. 10 schematically shows integrity links in a cloud once an entity islost;

FIG. 11 schematically shows integrity links in a cloud once an entityjoins;

FIG. 12 shows the arrangement of keys on a device and lookup pointduring registration of a device;

FIGS. 13, 14 and 15(a) show the arrangement of keys when a device joinsa cloud;

FIG. 15(b) schematically shows the establishment of an integrity linkbetween two entities;

FIG. 15(c) schematically shows the process of sending data trafficbetween two entities in a cloud;

FIG. 15(d) schematically shows the process of an entity joining a cloud;

FIG. 16 schematically shows the arrangement of modules for the softwareof the invention;

FIG. 17 shows the relationship between software modules in multipleclouds;

FIGS. 18, 19 and 20 shows examples of the relationship between devicesthat share multiple clouds;

FIGS. 21 to 47 show sample graphical user interfaces (GUIs) that can bepresented to users of the invention;

FIG. 48 shows a flowchart of a start-up procedure;

FIG. 49 gives an example of a logon screen;

FIG. 50 shows a flowchart of a device start-up procedure;

FIG. 51 shows a flowchart of a procedure for a join lookup request;

FIG. 52 illustrates a cloud join process using a flowchart;

FIG. 53 shows a flowchart of a cloud join procedure;

FIG. 54 shows a flowchart of a cloud start-up procedure;

FIG. 55 shows a flowchart of a cloud initialisation procedure;

FIG. 56 shows a flowchart of creating a single view over all devices ina cloud;

FIGS. 56A, 56B and 56C show a schematic of the relationship betweendevices, across a single view;

FIG. 57 shows a flowchart of a cloud start-up procedure;

FIG. 58 shows a flowchart of object communication;

FIG. 59 shows a flowchart about device lookup and connection procedures;

FIG. 60 shows a flowchart of a message switching procedure;

FIG. 61 shows a flowchart of a cloud integrity maintenance procedure;

FIG. 62 shows al flowchart of peer information synchronisationprocedure;

FIG. 63 shows a flowchart of a cloud information synchronisationprocedure;

FIG. 64 shows some details about lookup point message handlingprocedure;

FIG. 65 shows some details about join query messaging procedure; and

FIGS. 66 to 70 provide some additional examples of screens that allowusers to operate a software application that embodies the invention.

BEST MODES FOR CARRYING OUT INVENTION

Examples of a secure partition of the internet will now be described. Inthis description a secure internet partition will be referred to as a“cloud”.

Device—any device having a processor and can be connected to theinternet (such as using TCP/IP) can be connected to a cloud to form partof the secure internet partition. Such a device must also meet certainminimum system requirements. Examples of a device include: PC, (with anyoperating system, such as “Windows”, “Linux”, “Macintosh”, or opensource operating systems); PDAs, PPC, with whichever operating system,such as “Palm OS”, “Windows CE/Mobile” etc; Mobile telephones orsmartphones, such as, “BlackBerry”, Java phone, Nokia “Symbian”operating system mobile phones; and Embedded devices.

Entity—An entity is the basic unit (or node) in a virtual privatenetwork (VPN) or “cloud”. An entity is a collection of objects and canbe created by a device or a cloud or VPN itself.

Objects—An object is associated with an entity (i.e., device or cloud).The objects contain functionality which allows access to data andfunctionality on the devices in a cloud. That is, an object is acollection of actions. An object can create an instance of an action.Objects can be added to the cloud from each device in the cloud so thatthe objects in a cloud are available from all of the trusted devices.

Cloud—A VPN created between known trusted entities. The cloud is awareof which devices are trusted and the status of these entities. Also acloud can be a VPN of devices and/or other clouds. Objects can be addedfrom each entity in the cloud.

Lookup point—A lookup point is used in the system to allow the entitiesto find each other. The shared lookup point allows centralizedregistration and control of clouds. The lookup point can be located onone of the devices in a cloud. Alternatively, the lookup point can alsobe on a separate device.

These concepts will be explained further in reference to the FIGS. 1 to20

FIG. 1 schematically shows the architecture of a single cloud 100. Thecloud 100 is created from four entities A to D. Entity A is a cloud thatis itself comprised of a set of devices including a desktop computer,notebook, PDA and smartphone. Entity B is another desktop computer.Entity C is another smart phone. Entity D is a further cloud. Eachentity A to D is configured behind a firewall 106 and connected to theinternet 102. There is a shared lookup point 104 for all four entities Ato D, that is maintained on another device.

Each entity A to D is associated with it different content labelled 108a to 108 d respectively. Content 108 a to 108 d is shared on the cloudin the form of objects. On each entity A to D there is full access toand manipulation of all the content 108 a to 108 d. This is shownschematically with the reference numeral 110.

FIG. 2 shows three separate clouds E, F, and G that use a shared lookuppoint 104. Cloud H exists separately and has a private lookup point 105.The entities of clouds E, F, and G use the shared lookup point 104. Theentities of cloud H use a private lookup point. Cloud H is isolated andany device that is to be joined to Cloud H needs to be aware of andregistered with the Cloud H private lookup point 105.

If all entities in a cloud 114 share a lookup point 104, the cloud isconsidered centrally managed. There are four entities A, B, C and D thatmay each be a device or a cloud, which together form a centrally managedcloud 114.

All traffic between entities is optionally encrypted. At the very leastall entities must be authenticated. If encryption is used the encryptionis entity A, B, C or D specific as well as cloud 114 specific.

Further details are shown in FIGS. 3 and 4.

The Integrity link is indicated as 120 in the Figures. Only a singlelink is ever established between two entities but this link may be usedfor multiple types of information links such as data and integrity. Inthis example, links 120 represents integrity links. These integritylinks 120 maintain a complete circle around all entities in a cloud.These integrity links 120 are used to verify the credentials of eachentity A to D in the cloud 116. Each entity in a cloud is preferablyverified twice by each of two other entities in a cloud. For example,entity B is verified by A and C that are on the each side of B'sintegrity links 120.

The verification is done via a challenge-response mechanism thatconfirms that the entity is who it says it is, and also that the entityknows who the user accessing the system is. If A is challenging B, thechallenger A creates a random data sequence that is then encrypted usingthe public key of the entity being challenged B. Entity A sends thisdata to entity B. The challenged entity B then decrypts the random datausing its private key and re-encrypts it using the public key of thedevice that challenged A. The re-encrypted data is sent from B to thechallenger A for a match to be made. If matched, positive verificationhas taken place.

Verification is repeated at intervals, in this way if security of adevice is compromised or a device goes off-line the integrity circle isautomatically readjusted to remove that entity (discussed in furtherdetail below).

The Data links are indicated as 122 in the Figures. In FIG. 3, thedotted lines represent data links 122 that are used for communicatingbetween entities A to D in the cloud 116. A data link 122 is firstestablished as an integrity link 120 to verify the other entity. Thedata link 122 is not valid until integrity is established. Data can betransported by relaying if no direct link exists between the entitieswishing to exchange data.

These data links 122 are created as needed and closed when idle. Adirect data link 122 between entities is desirable when and occursautomatically when multiple messages are sent between the two entities.The direct data link 122 is then closed when it is idle for apredetermined period of time. To open the link between two entities thatdo not already have integrity link between them, such as A and C, thenthe entities will verify each other first.

This data links 122 may be used for synchronizing cloud stateinformation such as the current list of trusted entities. The data links122 may also be used for keeping the cloud 116 records synchronizedacross the cloud. The data links are used for transferring all databetween entities. Data sent over a data link contains header informationidentifying the data tape. Synchronization means that each entity isable to view an up to date list of content available on all entities Ato D of the cloud 116. These records contain cloud settings but can alsobe application specific. The data links 122 may also be used forcommunicating with cloud objects. Header information in a packet sentover a data link is able to address a particular cloud object.

The Lookup links are indicated as 124 in the Figures. The cloud 116 alsocomprises lookup links 124 to the lookup point 104. In the example shownin FIG. 3, the lookup point is a computer that has a DBMS on it. Thelookup point should have a URL, or a fixed IP address so it can alwaysbe found. The lookup links 124 are used when an entity, say A, attemptsto register the current location of the entity A with the cloud 116. Theentity A can find other entities B, C and D via the lookup point 104.This registration communication is encrypted using a public/private keymechanism that exchanges symmetric keys to use for the entity A'ssession.

The lookup point 104 holds the locations of entities A, B, C and D.Lookup point 104 controls the creation of new entities for a user. Itcan also control the joining of those entities into a cloud.

An device master key is held on the lookup point for each registereddevice. This key is used to lock all the private data for the cloudyapplication. If a device should be stolen, for example, then by blockingreceipt of this key from the lookup point 104, any access to a user'sclouds using the stolen device is prevented.

The lookup point 104 is used to register the name of each user's clouds.Also it can register the invitation password that is a secondarypassword needed to join the cloud if the user so chooses.

A Join Query can be performed on the DBMS stored on the lookup point 104to obtain the list of clouds a user can join. A Join Lookup can beperformed on the lookup point 104 to connect to a cloud to perform ajoin. The lookup is performed by matching the cloud name and optionallythe invitation password.

A cloud 130 can also be privately managed and an example of this isshown in FIG. 4. For simplicity, the same reference numerals have beenused to represent the same items as shown in FIG. 3.

This cloud 130 is similar to cloud 116 except that the lookup point islocated on one of the cloud devices, in this case a device of entity B.In this arrangement the lookup point may manage both the one cloud, orelse multiple clouds. Unlike the cloud 116, entity B should have aregistered URL or a fixed IP address so that the other entities A, C orD can find it to access the lookup point. The lookup point can beintegrated into the same software as is running the cloud.

The relationship between devices and entities will now be described inwith reference to FIGS. 5(a) to 5(c).

In FIG. 5(a) a device is able to create an entity. Once an entity iscreated (i.e., by connecting a device to a cloud) then functionality canbe added by linking to the entity software objects on the device. Inthis example a real object 134 on the device 136 is added to an entity135 by creating a virtual object 138 that links back to the real object134. The end result is the entity I.

Multiple entities can be joined to create further entities. In FIG. 5(b)entities I, J, K and L have been joined to create a new entity M. Thereis no limitation that the entities I to L must have been created from asingle device. For example, entity M may represent four devices joinedtogether to create a cloud, or four clouds joined together to create thecloud M. Alternatively, the cloud or two devices and two clouds joinedtogether to create a cloud, etc. An example is shown in FIG. 5(c) whereEntity X is created by joining entities M and N. Entity M is comprisedon entities I, J, K and L and entity N is created by joining entities Oto R.

FIG. 6 shows how objects work to create a single view across multipledevices. In this example there are three devices 136, 140 and 142 thathave been joined together to create a cloud 144. There are three typesof objects in FIG. 6: Real objects 146, 148 and 150; Virtual Objects152, 154 and 156; Remote Objects 158, 160, 162, 164, 166 and 168.

Real objects 146, 148 and 150 are actual objects on the device 136, 140and 142 respectively. These objects allow access to data andfunctionality from the device. There may be multiple real objects on adevice, each providing a certain type of functionality.

Examples of real objects are: File Browser—allows access to files andfolders; Mail Browser—allows access to email content and functionality;Calendar Browser—allows access to calendar; Music Streamer—allows accessto music content; Voice module—allows access to device microphone andspeakers for VOIP; Video Streamer—allows access to video content; Chatmodule—allows text messaging; MediaPlayer Remote—allows remote controlof a devices media player; Remote Application Module—allows remoteapplication viewing and interaction; Advertisement Module—has cloud userspecific information and can reach out to the web and pull inadvertisements; Banking Module—stores bank credentials on a safe deviceand performs transactions remotely; Printer Module—allows access to aprinter from the cloud; Panic Module—displays panic alerts from anotherdevice; Web RSS feed module; FTP Server module—allows access to existingFTP servers from the cloud; BLOG update module—allow updating of a BLOGfrom the cloud; Legacy module—allow access to a legacy application overthe cloud; Database module—allow database access over the cloud; Webcamera module—access streaming video in the cloud.

Virtual objects 152, 154 and 156 are the objects added to an entity 135,170 and 172 that link to the real objects 146, 148 and 150 respectively.Each virtual object linked to a real object can have individualpreferences set. This allows one virtual object in one entity to allowaccess to different data then another virtual object from the same realobject in another entity. In this way, different folders may be sharedin each of the entities from the same file sharing object.

Remote objects 158 to 168 are objects that are linked to virtual objectsvia data links 174. The remote objects 158 to 168 are used to access avirtual object from another entity on the cloud.

The surface of a remote object and a virtual object is identical; onlythe underlying communication mechanism is different. Entity 135 hasaccess to objects 152, 158, 160 which via the underlying communicationmechanisms allows access to the real objects 146, 148 and 150.Similarly, entity 170 has access to objects 154, 162 and 164 which viathe underlying communication mechanisms allows access to the realobjects 146, 148, and 150. And again, entity 172 has access to objects156, 166 and 168 which via the underlying communication mechanismsallows access to the real objects 146, 148, and 150. This functionalityand access method allow each of the entities 135, 170 and 172 to haveaccess to the same functionality and data using a single view sharedacross all three devices 136, 140 and 142.

FIG. 7 schematically shows another type of object which is themetaobject. This is similar to a virtual object except that instead oflinking to a real object, a metaobject links to other objects in thesame entity; the linked object can itself be a remote object, virtualobjects or other metaobject. For example a standalone meta-object couldbe implemented using a real object-virtual object pair, where the realobject is only active on one cloud.

In this example a cloud 176 has been created between the three entities178, 180 and 182. The real object 184 on device 186 has been shared withthe cloud 176 via the virtual object 185. The metaobject 188 links tothe remote object 190.

There are two remote metaobjects 192 and 194 which are identical infunctionality to normal remote objects 190 and 196. Here, metaobject 188obtains its functionality and data from remote object 190. The realobject 185 obtains its functionality and data from real object 184.

The metaobject 188 contains additional logic that is able to createadditional functionality not contained in the object(s) it links to. Asingle metaobject is able to link to multiple (potentially all) otherobjects in the cloud.

Examples of meta-objects include: Alert object—watches one object for achange and acts on another; Virtual Folder object—uses a File Fetcherobject to add a virtual folder so that any data saved to the virtualfolder is automatically moved to a backup location, and for example, ona mobile device with limited storage space this can be used to allow forunlimited photo storage; Mail Attach object—link all the file fetcherobjects and a mail object to implement a Send Mail action that canattach files from anywhere in the cloud; Backdoor Object—allow access toall cloud objects to implement a backdoor for any legal requirements onthe software; Panic Alert Object—links to Panic Module Objects tosystematically or simultaneously alert other devices.

FIG. 8 schematically shows the relationship between actions and objects.Any object contains actions. In this example, object 194 containsactions (i), (ii) and (iii). The meta-object 196 also contains actions(iv), (v) and (vi).

The use of actions with objects is now described with reference to FIG.9. A cloud 198 has been created between two devices 200 and 202. Avirtual object 204 has been added to entity 206 from a real object 208on device 200. A metaobject 210 has been added to entity 206 on device200. The real object 208 contains two actions (i) and (ii). Theseactions are available on the virtual object 204 as (vi) and (vii) and onthe remote object 220 as (vi) and (vii).

An instance of action is created to use an action. On device 202 threeinstances of action (vi) on the remote object 220 have been created as(pi), (pii) and (piii). As an example if the object is a “FileFetcher”and the action is “GetFile” then we may be doing three simultaneous filerequests (pi), (pii) and (piii). Action (vi) on object 220 on entity 226maps to action (vi) on object 204 on entity 206. This maps to action (i)on object 208 on device 200.

The action instance (ai) on device 202 maps to the action (mi) from theremote meta object 232 on entity 226. Action (mi) maps to the action(bi) on the meta object 210 on entity 206. Action (bi) creates an actioninstance (bii) of the action (vi) on the virtual object 204. Action (bi)in this example only interacts with a single object, though it ispossible to interact with several action instances from differentobjects or the same object.

The use of the integrity links described above to detect a missingentity will now be described with reference to FIG. 10(a). In thisexample, there are four entities 236, 238, 240 and 242 that have formeda cloud 244 that includes a look up point 246. An integrity link isestablished by links 248, 250, 252 and 254 that completes a circlelinking all entities 236, 238, 240 and 242 together. As shown in FIG.10(b), if entity 236 goes off line, then a new integrity link 256 isestablished between entities 238 and 242. All other links remainunaffected.

In the same way the links can be used to locate a new device that wishesto connect to a cloud. With reference to FIG. 11, cloud 260 isestablished between entities 238, 240 and 242. Integrity links 248, 250and 256 exists between these entities.

If entity 236 comes online, a connection 262 is established with thelookup point 246. Entity 236 requests the lookup point 246 for thelocation of cloud 260. The lookup point 246 determines that entity 238is the registered cloud 260 contact point so the lookup point 246 asks264 entity 238 if a connection from entity 236 is permissible. It hasalso transferred location information about entity 236 to entity 238. Ifentity 238 replies 266 that the connection is permissible, the lookuppoint 246 communicates 267 with entity 236 the location of entity 238.

A connection 254 is then established between entity 236 and entity 238.Entity 236 and entity 238 challenge and verify each other (described infurther detail below). Entity 236 has its cloud status informationupdated by copying the information from entity 238. The updateinformation is a synchronization of the status of the other cloudmembers and the list of cloud members. This status update (including theonline and verified status of the other entities in the cloud) allowsentity 236 to know where it slots into the integrity link circle andwhat is available to it on the cloud. Then entity 236 and 242 establisha new integrity link 252 to complete the integrity link circle.

For increased security, before a device can connect to any cloud it mustfirst register. This will be described with reference to FIG. 12. Usingtheir device a user must enter registration information. Theregistration information can normally include: a username and apassword.

In this example, device 270 establishes a connection 272 with the lookuppoint 274. A registration message is sent over the connection 272containing: registration username; salted hash of the registrationpassword; unique identifier for the device; and local network addressinformation.

If the registration is accepted by the lookup point 274 then thefollowing information is returned 276 to the device 270: master key 278used to unlock the cloudy application information, (this includes:device information; device security keys; encrypted file system key;cloud information; cloud security keys).

The cloudy application is unlocked on the device 270 by using both alocally stored key 280 which never leaves the device and the lookuppoint stored information that is the master key 278 which is neverstored on the device.

The use of security keys when an entity joins a cloud as described inFIG. 11 will now be described with reference to FIG. 13. A cloud 288 isestablished between devices 290 and 292. Device 290 contains thefollowing security information: Cloud symmetrical key 294; Lookup pointpublic key 296; Private key 300; Public key 302; and Public key 304.

Cloud symmetrical key 294 is a randomly created sequence unique to eachcloud. All of the cloud specific portion of a data message is encryptedwith this key 294 combined with a randomly created seed that changes attimed intervals and is different for each entity (described in furtherdetail below with reference to FIGS. 15(b), (c) and (d)).

Lookup point public key 296 is used to communicate with the lookup point298. Private key 300 for device 290 is used to unlock messages sent fromother devices. It is only used for initial integrity link establishmentas symmetrical keys are exchanged during integrity link establishment.Public key 302 for device 290 is handed to trusted entities so they cancommunicate with device 290 during integrity link establishment. Publickey 304 for device 292 is received from device 292 so device 290 canestablish an integrity link with device 290.

Device 292 contains the following security information: Cloudsymmetrical key 294; Lookup point public key 296; Private key 306 fordevice 292; Public key 304 for device 292; and Public key 302 for device290.

Each entity 290 and 292 each contain further keys which are omitted inthis example for simplicity but are described in further detail belowwith reference to FIGS. 15(b), (c) and (d).

Device 310 is not a member of the cloud 288 and only contains: Lookuppoint public key 296; Private key 312 for device 310; and Public key 314for device 310.

The lookup point 298 contains: Lookup point public key 296; and Lookuppoint private key 316.

Based on the cloud 288 described in FIG. 13 the method of device 310joining the cloud will now be described with reference to FIG. 14.

Firstly, the user on device 310 enters the following information intothe cloudy application: cloud name (C); cloud invite number (I); clouduser name (U); and cloud user password (P).

The device 310 sends 330 to lookup point 298 a join lookup messagecontaining cloud name (C) and invite number (I). The lookup point 298searches for this cloud and returns 332 the unique entity identifier forthe cloud.

The device 310 then sends 334 a connection request for this entity ID tothe lookup point 298. Lookup point 298 sends 336 a connection request toentity 290. Device 290 replies 338 to lookup 298 with a connectionaccepted message. Lookup point 298 sends 340 to device 310 a requestaccepted message.

Next device 290 and device 310 establish a connection 342. Firstly,device 310 constructs a join message to send to device 290. The messageis self encrypted using hashed versions of C, U, P and I and a randomsequence (S). Device 290 checks the join message, and if OK, the device290 requests information about device 310.

In response, device 310 sends the following information to 290: Publickey 314 for device 310; and EntityID for device 310.

Device 290 receives this information and replies with an invitationcontaining: Cloud symmetrical key 294; Public key 302 for device 290;and EntityID for device 290.

Device 290 and device 310 establish an integrity link and the cloudstatus are synchronized over this link. Status information includes alist of the EntityIDs for each member of the cloud. It receives theonline status of each cloud entity. Cloud records are synchronized,these records contain cloud, entity and object information. The cloudrecord contains a list of the entities in a cloud as well as cloudusers/pwds. The cloud member records (one for each entity) contain alist of the objects for that member as well as the display name for themember. The object records (one for each object) contain a list of theclasses the object supports as well as the available functionalitytypes.

The synchronisation also includes the public keys for the other cloudentities. In this way entity 310 receives the public key for entity 292so that entities 310 and 292 can create an integrity link and completethe integrity circle. FIG. 15(a) shows the final state.

Device 290 contains the following security information: Cloudsymmetrical key 294; Private key 300 for device 290; Public key 302 fordevice 290; Public key 314 for device 310; and Public key 304 for device292.

Device 292 contains the following security information: Cloudsymmetrical key 294; Private key 306 for device 292; Public key 304 fordevice 292; Public key 314 for device 310; and Public key 302 for device290.

Device 310 contains the following security information: Cloudsymmetrical key 294; Private key 312 for device 310; Public key 314 fordevice 310; Public key 302 for device 290; and Public key 304 for device292.

If there had been a further entity positioned in the integrity circlebetween 290 and 292, during the synchronization between entity 310 and290, entity 310 would have also received the public key of the furtherentity. In this way, if entity 210 and the further entity wanted toshare data rather than relay it through entity 290 or 290, entity 310and the further entity could establish a direct integrity link byconducting a verification challenge and request and transmitting datatraffic over that new connection.

Further to the cloud symmetrical key 294 that is a static key and commonto all entities in a cloud, further dynamic keys are used to establishintegrity links and to exchange data. This will now be described withreference to FIGS. 15(b), (c) and (d).

Referring first to FIG. 15(b)(i) the integrity link challenge andresponse method, including key exchange will now be described. In thisexample, an integrity link is established between entity A & B.

On entity A: a randomly created sequence is generated (and at intervalsregenerated) for each challenge, called here the integrity dynamic key.This integrity dynamic key is used as a symmetrical key AB′ 600. AB′ 600is encrypted using the public key of B 304 and this encrypted version issent 604 to B as a challenge.

On entity B: the challenge is received and decrypted using the privatekey 306 of B; the decrypted version of AB′ 600, shown as AB″ 608 isstored on B; AB″ 608 is encrypted using the public key 302 of A and theresponse is sent back 612 to A.

On entity A: the response is received and decrypted using the privatekey 300 of A; a comparison of the decrypted data and the original AB′600 is made and if a match is made the link is marked as validated; anaccepted message 616 is sent back to B.

On entity B: the accepted response is received and the link is marked asaccepted.

This method is for entity A to challenge entity B. There is also achallenge from entity B to entity A in the same way, but, in this casethe integrity dynamic key used is BA′620. This method is shown in FIG.15(b)(ii). The original challenge received on B will trigger a counterchallenge from B if B needs to verify A. The two challenges can occursimultaneously.

Once an integrity link from A to B and from B to A is marked as acceptedthen the data channel over that link is opened. The final state is shownin FIG. 15(b)(iii) where the above process is repeated at the nextchallenge cycle (for example, every 10 seconds). There can be atemporary overlap period during which the old keys (AB′, AB″, BA′, BA″)are still valid for the data link. During this overlap period both theold and new versions of the integrity dynamic keys are valid. Thisallows the data-link to remain open during subsequent challenges.

The method of encrypting data traffic between the two entities A and Bwill now be described with reference to FIG. 15(c).

The cloud desires to send data D from entity A to entity B. An integritylink has been established as described with reference to FIG. 15(b) sothat entities A and B have exchanged integrity dynamic keys.

For each cloud that entity A is a part of, entity A randomly generates asequence R that is used for sending data messages. This sequence iscombined with the cloud static symmetrical key C to produce CA′ 650, anew data dynamic symmetrical key. R and thus CA′ are regenerated attimed intervals independent of any challenge-responses occurring.

On entity A: a new message is started 656; R is encrypted 652 usingAB′600 and added 654 to the header 660 of the message 656 which containsaddressing information; D is encrypted 664 using CA′650 and added to thebody 662 of message 656; the message is sent 668 from entity A to entityB.

On entity B: the message is received; the header 660 is decrypted 690using AB″ 608 and R′ is extracted 692; cloud static symmetrical key C294 and R′ are combined 694 to produce CA″ 650; CA″ 650 is used 696 todecrypt the message body 662 and extract 700 the data D.

Network optimization allows a flag to be set in the header to tell B toremember the header. If the message header is the same for sequentialmessages between two distinct peers a flag is set in the header tosignal that the recipient (in this case entity B) should cache theheader. The next message can then have a flag set that tells entity B touse the cached header.

If entity A wished to send messages to an entity C that also was amember of the same cloud, entity A uses the same value R that was usedin sending messages to entity B.

For simplicity this example has been described with entities A and Bsharing only the one cloud. If entities A and B were both members to asecond cloud and entity A wished to communicate with B, a furtherseparate random sequence R would be generated and used whencommunicating on that cloud.

The process of joining a cloud will now be described with reference toFIG. 15(d) wherein entities A, B and C are members of the same cloud andhave challenged each other and exchanged symmetrical keys.

Entity D is in the process of joining the cloud. Entity D has receivedthe invitation containing the public key of entity C and the staticcloud key and has sent its' public key to C in the join request.

A challenge has been performed successfully and C and D have exchangedintegrity dynamic symmetrical keys.

Entity D is in the process of requesting the public key of B from C sothat it can challenge B and complete the integrity link.

The methods of registration, joining, departing, creating a cloud andsharing content on a cloud are controlled by application software thatis installed on each device and lookup point to cause the devices tooperate according to the methods described above. Examples of suitableprogramming language for this application software is C++ and Java, butany other programming environment may be used instead, or in addition.

FIG. 16 shows the main software modules of the software. The software isdivided into three parts: Graphical User Interface (GUI) 400, which isthe user interface; Core 402, which maintains security deviceconnections and clouds, and is the basic engine that creates and linksentities; and Objects 404, which add functionality and data to entities.

New applications can be created by changing the GUI and the Objects. Forexample: File sharing by adding a file fetching object that can show andaccess folders and files; Messaging by adding a chat object that allowsone device to send messages to another; Voice over Internet Protocol(VOIP) hay adding a voice object that can send voice data from anattached device; and other applications.

The design of the software is shown schematically in FIG. 17. The corecontains a Main Manager 410 that creates and initializes all of thesubsystems and clouds.

The OSWrapper 412 is a software module that communicates with theunderlying device. It provides encrypted file storage and a library ofpossible objects that new/existing entities can use. The OSWrapper 412is used to create virtual objects and remote objects. The Networking 414is a software module that manages all of the communications betweendevices, it performs: entity lookups; integrity link establishment;message relaying; and device specific encryption.

The cloud 416 is a software module that manages a particular entity andits associated cloud on a device. There is an instance of this modulefor each cloud. The cloud 416 performs: Cloud specific encryption; Cloudstatus synchronization; Cloud record synchronization; Object and actionmessaging; and Cloud integrity link maintenance.

The instance of the cloud 418 shows the layout for a simple cloud on thedevice. The OSWrapper 420 is obtained directly from the main managerOSWrapper 412. The Entity Networking 422 is obtained from 414.

Cloud 424 is another instance of a cloud managed by the main manager410. It contains the same software as cloud.

Cloud 426 is a cloud that is built on cloud 424 that is an entity oncloud 426 is in fact cloud 424. Cloud 426 refers to cloud 424 ratherthan back to the main manager 410. The OSWrapper 428 is obtained fromthe OSWrapper 430 from cloud 424. Any saved non-user data from cloud 426is automatically propagated across cloud 424; this includes cloud statusbut not data from an object data request. The libraries of possibleobjects that can be added to cloud 426 are those from cloud 424. TheEntity Networking 430 is obtained from the entity networking 432 fromcloud 424.

Further, cloud 434 is a cloud that is built on cloud 426. The OSWrapper436 is obtained from the OSWrapper 440 from cloud 426. Any cloud statusinformation from cloud 434 is automatically propagated across to cloud426. Again, the libraries of possible objects that can be added to cloud434 are those from cloud 426. The Entity Networking 442 is obtained fromthe entity networking 444 from cloud 426.

With reference to FIG. 18, the software in relation to twointerconnected clouds will now be described. There are in total fivedevices and two clouds. Cloud A contains devices (in this case they arealso entities) 450, 452 and 454. Cloud B contains devices 454, 456 and458. The links 460 comprise the integrity link for cloud A. The links462 comprise the integrity link for cloud B.

If a user on device 450 interacts with cloud B and data needs to be sentto a real object on device 456. Entity networking message is sent fromdevice 450 to Device 456. This message is relayed to the cloud B contactpoint (device 454) for cloud A.

Software and links on three clouds A, B and C spread over five devices470, 472, 474, 476 and 478 will now be described with reference to theschematic drawing of FIG. 19.

Cloud A is comprised of entities existing on devices 470, 472 and 474.Cloud B is comprised from entities existing on device 470, device 476,device 478, and Cloud A. Cloud C is made from entities existing ondevice 472 and device 474.

The integrity link for Cloud A is comprised of the links 480 thatconnect device 470 to device 474, device 470 to device 472, and finallydevice 472 to device 474. The integrity link for Cloud B is comprised oflinks 486 that connect cloud A to Device 478, cloud A to device 470,device 470 to device 476, and device 4 to device 478. Finally, theintegrity link for cloud C is link 490 that links device 472 to device474.

Software and links on a further example will now be described withreference to FIG. 20. In this example there are four clouds A, B, C andD.

Cloud A contains devices 500, 502 and 504. Cloud B contains device 500,506, 508 and Cloud A. Cloud C contains devices 502 and 504. Finally,cloud D contains cloud A, cloud B and cloud C. Links 510 comprise theintegrity links for cloud A. Links 512 form the integrity link for cloudB. Links 514 form the integrity link for cloud C. Finally, the links 516form the integrity link for cloud D.

An application of the clouds set out in FIG. 20 may be as follows: CloudA=Boss's work cloud; Device 500=Boss's office PC; Device 502=Boss'sMobile phone; and Device 504=Boss's Laptop. Cloud B=Boss's Sharingcloud; (Cloud A=Boss's work cloud (Allows access to shared content fromthis cloud); Device 500=Boss's office PC (Allows access to content on PCthat may not have been shared as part of Cloud A); Device506=Receptionists PC (Allows access to Boss's schedule etc.); and Device508=Assistants PC; Cloud C=Boss's private cloud between his mobile 502and laptop 504; and Cloud D=Administrators cloud (It is possible to haveno private data accessible to this cloud from it's members, and this mayallow only access to device maintenance and monitoring objects).

An example of using the software will now be described with reference toFIGS. 21 to 47.

FIG. 21 shows the GUI for the look-up point GUI. For example, this couldbe the interface presented to the user of the server that operates thelookup point 104 of FIG. 2. In this GUI, the devices registered with theCloudy administrator are registered with the system.

FIG. 22 shows the same GUI but in this case all the users registeredwith the administrator are displayed. Here, there is one user “Jason”that is registered and they are associated with 39 of the 200 devicesand 14 of the 400 clouds. This means that the user “Jason” is able toregister 200 separate devices with the lookup point, and create 400clouds using those devices. Currently, 39 devices have been registeredalong with 14 clouds.

From the user's perspective the interface presented to them on theirdevice, which could be any of the devices discussed above, is shown inFIG. 23. In this example the device is a personal computer and isreferred to as “TELPAC-DEV”. This is the introduction/welcome screen forthe user.

If the user is already registered with the lookup point the user canselect “Old” to indicate that they are an existing user. As shown inFIG. 24 they are prompted to enter their username and password. Once theuser clicks “OK” this information is then sent to the lookup point aspreviously discussed with reference to FIG. 12. The device then receivesfrom the lookup point a key that unlocks the application on the device.Now the full functionality of the software application on the device isavailable to the user.

As shown in FIG. 25 the application is running but the device is notconnected to any clouds. To create a cloud the user selects “Create NewCloud” and the dialog box appears as shown in FIG. 26. The user entersthe name of the cloud, their user name and their password. Thisregisters the new cloud Demo with the lookup point.

The display is synchronized with the lookup point to cause a summary ofthe cloud Demo to be displayed to the user as a expandable tree as shownin FIG. 27. Here the cloud is comprised of three objects: files, mailand devices. Currently no content is shared and TELPAC-DEV is the onlydevice on the cloud.

If the user wishes to share their mail on the Demo cloud they select“local mail sharing” a pop up box that appears by clicking on summary ofthe Demo cloud. This causes the dialog box of FIG. 28 to appear and theuser selects the check box “Share mail”. This causes the device name“TELPAC-DEV” to be listed under the “Mail” heading in the summary of theDemo cloud as shown in FIG. 29. Bay selecting TELPAC-DEV under the“Mail” heading a summary of the mail available on TELPAC-DEV isdisplayed on the right hand side of the interface. Using the summary theuser can navigate around the mail folders stored on TELPAC-DEV.

The user can also share files. As shown in FIG. 30 by clicking on theDemo cloud summary the user can select the option “local file sharing”.This causes the dialog box of FIG. 31 to be displayed. The user canselect “Add” from the dialog box causing the dialog box shown in FIG. 32to be displayed. Here the user enters the title the files should belisted in the summary as, and in this example the name “Docs” is chosen.The user is also able to browse to select the folder to be shared. Inthis example the folder is identified by the path name “C:D\Documentsand Settings\Jason\My Documents”. The user selects “OK” to return theuser to the dialog box of FIG. 31, but, as shown in FIG. 33 the selectedfolder and share name is listed in the dialogue box. By selecting “OK”in the dialogue box, the folder is now made available on the cloud. Thisis shown in the updated summary of the Demo cloud shown in FIG. 34 whereTELPAC-DEV device is listed under the heading “Files”. A summary of thefolders that are shared by TELPAC_DEV is/are displayed on the right handside of the interface.

The user may also use the cloudy application from a different device. Inthe following example the user is now using a PDA called WM_Jason.Interfaces that may be presented to the user on the PDA will now bedescribed.

The user is presented with a welcome screen as shown in FIG. 35.Similarly to FIG. 24 the user must login to unlock the application asshown in FIG. 36.

As shown in FIG. 37 once logged in no content is visible as the user hasnot yet registered with a cloud. The steps of registering with the cloudis shown in FIGS. 38, 39 and 40. As described with reference to FIG. 14,firstly the user selects to “join a cloud” and enters the cloud name(which can be from a pick list created from the inner join), their username on the cloud, their password and cloud invite number. In this casethe user has selected to join the cloud called “Demo”.

The user's device automatically joins the cloud by creating an integritylink to one or more devices in the cloud and the status of the cloud arethen synchronized over this link. This synchronization causes the datathat is already available on the cloud to be accessible by the device.

As shown in FIG. 41 the cloud Demo has content is available. By clickingon heading Demo the content tree list is expanded as shown in FIG. 42.This shows that on the cloud Demo has two Devices that areconnected—that is devices “TELPAC_DEV” and “WM-Jason”. From the deviceTELPAC-DEV that is connected to the cloud mail, contacts and files areavailable.

FIG. 43 shows how the content on the TELPAC-DEV can be navigated usingthe interface on the device. “TELPAC-DEV” under the “Files” heading canbe selected to display a tree diagram of the folder shared under thename “Docs” and all the subfolders listed underneath. If the subfolder“Telpac” (not shown) is selected then a list of documents included inthat folder is then displayed as shown in FIG. 44. By selecting any oneof these documents, the document will be downloaded to the device fromTELPAC-DEV device using, preferably, a direct data link between the twodevices.

As a further example the user can select the folder “backups” from whichcontains graphic files that can be viewed on the device as shown in FIG.45.

Referring back to FIG. 42, TELPAC-DEV under the mail heading can beselected and this presents the user with a summary of the mail folderson TELPAC-DEV that have been shared as shown in FIG. 46. Using thesummary tree a folder can be selected to present the user with detailsof the summary of the e-mails that can be accessed using the cloud asshown in FIG. 47.

It will be appreciated by persons skilled in the art that numerousvariations and/or modifications may be made to the invention as shown inthe specific embodiments without departing from the spirit or scope ofthe invention as broadly described.

For example, the shared interface viewed by entities on a cloud could bepresented artistically in way, say, a person navigates through a houseto select devices such as bookshelves and TV's to access to sharedcontent therein.

EXAMPLES

Some additional embodiments and examples are now provided.

In FIG. 48, a flowchart (600) is used to outline the start-up procedureof the application, which in this embodiment is called “Razberry”. Thestart up is automated in this embodiment. When the application isinitiated on a device, a splash screen (601-“A”) is displayed, followedby a registration screen (602-“B”), where a user must enter a user nameand a password in order to proceed; these details being confirmed by theprogram from a lookup of this stored information. An example of a loginscreen is shown in FIG. 49. The login screen may also have a facility tomanage a user forgetting their user details, as shown in FIG. 49.

Once the user successfully unlocks the application (603-“C”), usingsecurity information returned from the lookup following a successfulregistration (refer to FIG. 50 for more detail), then the applicationchecks to see if the initial “Razberry” cloud is available on the device(604-“D”). If not (605), the user is invited to create this cloud. Ifthe initial cloud is already available on the device, this starts (606).Once this occurs a GUI is displayed (607), allowing the user to utilisethe “Razberry” application.

A check of the unlocked data is made (“D”), to see if the “Razberry”cloud has already been set up on this device. The device has not yetjoined the “Razberry” cloud (“E”) so a request from the lookup isperformed to find out which clouds the current registered user has.(Refer FIG. 51 for more detail). The results are checked (“F”), to seeif a “Razberry” cloud has previously been created. If it has (“G”), thenan administration password can entered by the user or a fixed one can beused by the application. This password is needed to add a new device toa cloud. The unique Cloud ID is checked (“H”) with the look-up. WheneverCloud ID check fails (“I”), the local Razberry Cloud data is removed. Ajoin is performed by the application (“J”) to try and join the RazberryCloud. If the join fails (“K”) the user is then prompted to start a newcloud. If the user chooses to start a new cloud (“L”) then the look-upis told to delete the exiting cloud. A new administration password isset (“M”) by the user or application. The Razberry cloud is created(“N”) using the new administration password. The existing Cloud isstarted up (“O”) using the locally stored data.

As explained above, the cloud includes a number of devices, and detailsof the registration of each device, is illustrated in a flowchart, asshown in FIG. 50.

A device registers (“A”) with the look-up by passing a unique randomlygenerated ID for the device along with the registration user name andpassword. The look-up checks the users registration (“B”) to confirmthat this device is registered under this user. Whenever this is anunknown device for the current user (“C”), then the look-up checks theregistration details for this user to see if they are able to add a newdevice. If a new device can be added (“D”), a new registration record iscreated for this device, on the look-up. The new registration recordcontains a randomly created security key. The randomly created securitykey is returned to device (“E”). The device unlocks its local cloudapplication data (“F”) using the randomly created security key.

As well, a user may have access to a number of clouds, and the procedurefor obtaining their list is shown as FIG. 51. The device requests a list(“A”) of available clouds tied to a user's registration. The loop-upreceives the request (“B”) and retrieves the list of clouds registeredfor the requesting devices registration. The list is returned (“C”) tothe requesting device. The list of available clouds (“D”) is received bythe device.

A process for allowing a user to join the clouds that they havepermission to access is shown in FIG. 52. The cloud name and invitationare sent (“A”) to the look-up to do a join look-up). The look-upsearches the registered clouds (“B”) for a match against the cloud nameand invitation for the current registration. The unique cloud identifierfor the matched cloud (“C”) is returned to the device. The devicereceives the cloud id (“D”) and performs a look-up using that id. Adirect connection is established (“E”) to the cloud via the Look-up(refer FIG. 59).

A join request is sent to the contact device for the cloud (“F”). Thecontact device is the current device registered with the preferredinitial point of contact with the cloud. This request contains the cloudname, invitation name and username/password for an invitation into thecloud. The received cloud joining credentials (“G”) are checked againstany active invitations for the cloud. The invitation (“H”) is verifiedby matching the cloud name, invitation and user name/password. A reply(“I”) that the joining is accepted is sent to the joiner. A request(“J”) to the joiner for its device information is sent. The deviceinformation (“K”) is sent back to the cloud contact device. Thisinformation contains the identifier for the device joining and thepublic key for the joining device. The received device information (“L”)is stored in memory. An invitation (“M”) is set back to the joinercontaining the cloud identifier, cloud security keys, a list of thecurrent device ids for the devices on this cloud and the public key ofthis device. The joiner adds the cloud (“N”) to the application data andstarts up and initializes the cloud. The joiner (“O”) replies to thecloud contact device that all is ok.

The cloud contact device (“P”) receives the ok and loads the joiner'sinformation that is stored in memory into the application data. Thejoining device (“Q”) is added the list of devices for this cloud. Averification process (“R”) is commenced between the joiner and the cloudcontact device. The standard synchronization process (“S”) between peersupdates the joiner with the security keys of the other devices on thecloud along with the device and object records for the cloud.

A process for having a user to create a cloud is shown in FIG. 53. Acreate message (“A”) is sent by the device to the look-up containing theunique identifier for the cloud, the name of the cloud and theinvitation to be used to join this cloud. The look-up (“B”) checks thatthe cloud name is not already used for the registration that the deviceis under. The same name can only be used for each registration. Thelook-up checks (“C”) that the current registration allows the creationof a new cloud. A record (“D”) of the cloud is added to the registrationdatabase. The device (“E”) is told by the look-up that they are allowedto create the cloud. Device (“F”) proceeds to start-up and initializethe cloud. Each device (“G”) contains a list of the unique identifiersfor the clouds that it is a member of. This list is updated with the newcloud identifier. A user is added to cloud (“H”). An invitation (“I”) isadded to the cloud which allows other devices to join this cloud. Thecreation of a new cloud (“J”) is notified to the GUI for presentation tothe user.

Once the clouds that the user can access are determined, the contentsfor each cloud can be made available to the user. A flowchart for thestart-up process for each cloud that is registered on a device isprovided in FIG. 54. The device (“A”) sends a message to the look-upasking it to confirm if a particular cloud unique identifier isregistered with the look-up. A list of the unique cloud identifiers isstored by the application on each device for clouds that the device is amember of. The look-up (“B”) searches for the cloud identifier in itsdatabase. The device (“C”) is returned the result of the look-up.Whenever the unique cloud identifier (“D”) is found on the look-up thenthe device proceeds to initialize the cloud. The GUI is notified (“E”)about the cloud being available for presentation to the user. If thecloud unique identifier (“F”) was not found on the look-up then thecloud is deleted from this device.

An initialisation procedure flowchart is provided in FIG. 55. For eachcloud already registered on a device, then a message to this effect issent (“A”) to the look-up. The cloud id is found (“B”) in the lookupdatabase. If found (“C”) a cloud is initialised (“D”). Each cloud (“D”)has a unique symmetrical encryption key which is used for cloud specificcommunications. Each cloud (“E”) has a integrity thread that is used tomaintain the integrity of the cloud, which includes: synchronization ofcloud data; maintenance of cloud state data; maintenance of cloudintegrity circle; and maintenance of cloud security. Each cloud (“F”)contains an object action worker thread that is used to process actionrequests for objects on this device. For a new cloud (“G”), cloudrecords are then added for the cloud, users, invites and members. Arecord is added (“H”) for this device record. Cloud records areregistered (“I”) for synchronization. All active cloud invitations areregistered (“J”) with an inviter module to allow other devices to jointhis cloud.

In FIG. 56, a flowchart is shown which indicates the steps in a processfor populating a single view across all the devices in a cloud object,which allows all the objects within a cloud to be presented to a user,for their further interaction with these objects. As illustrated in FIG.56A, the system has three main layers, a GUI, a communications core, andobjects, which represent data and functionality on a device. The diagramof FIG. 56A shows the arrangement for three devices. The first device onthe left operates as though its core extends across all three devices.This allows the GUI on the first device to access all of thefunctionality and data enabled by objects on all three devices. Thissituation is repeated for all of the three devices.

As indicated in FIG. 56B, the linking between cores is maintained acrossthe internet, or other network that connects the devices.

As indicated in FIG. 56C, for a particular grouping of devices (i.e., acloud) the above data records are maintained on each device. Theserecords are kept synchronized by a record manager in the cloud. Eachrecord is identified by a unique identifier which is different for eachcloud.

The “Cloud Record” is a master record for a cloud, which contains areference to the devices record, users record and invites record. Thisrecord is kept synchronized across the cloud and does not change after acloud's initial creation. The “Devices Record” contains a list ofreferences to the “Device Record” for each device in a cloud. Thedevices record is updated when a new device joins the cloud. The “DeviceA Record” is the record maintained for Device A. Device A creates thisrecord and is the only device that can update this record. The recordcontains a list of references to the Object Records that are maintainedfor each object on A. The “Object A1 Record” contains a list of thepossible actions that are performable on the object A1. Actions couldbe: get the list of folders, get the list of files, send all email, adda contact, etc. The record also lists the classes contained in theobject. A class is a predefined set of required actions. Examples ofclasses include: file browser, email browser, contacts, calendar etc. Ifan object has a particular class then it can be assumed that it containsa particular subset of actions. This allows for the standardization ofobjects.

A flowchart setting out the steps in object sharing is illustrated inFIG. 57. The steps referred to in the flowchart (“A”) to (“H”) arefollowed to carry out object sharing.

A flowchart of some possible object communication is provided in FIG.58. This also provides an example of interactions occurring via XML.Data in diverse formats is managed by a common standard, which may heXML, as shown in this example, or may be some other standard. However,because XML tends to be verbose and contain much redundancies, aspecific and more concise standard can be developed for use with the“Razberry” application, that only contains the information necessary forit to operate. In the example of FIG. 58, messages are passed back andforth using XML, to allow activities to occur. The steps (“A”) arecarried out as shown in the flowchart.

A flowchart setting out a method for the device connection and lookup isillustrated in FIG. 59. This utilises a connection matrix.

In FIG. 59, device R wishes to connect to device L (“a”) and sends adevice connection/look-up request to the look-up. The look-up searchesits device registration database (“b”) to retrieve network addressinformation abut device L. This information is the IP address on deviceL as well as the IP address seen by the look-up for device L. Thelook-up sends a request to the connection matrix for a new connectionlink. The connection matrix allocates two new network ports (“c”) thatare linked in order to transparently transfer data between the two.These two linked addresses M1 and M2 are returned to the look-up.

The look-up receives (“d”) the connection matrix. A connection requestis sent (“e”) to device L. This connection requests network addressinformation for device R and M2 (half of the connection link). Device Lreceives the request (“f”) and decides if it wants to accept theconnection. This decision can be based on allowed or banned IP addresslists. Device L replies (“g”) that the connection is accepted. Itconnects to M2 on the connection matrix (“h”). Device L attempts toestablish (“i”) a direct connection with device R. This directconnection attempt uses both the actual address of Device R and theaddress as seen by the look-up. Look-up receives (“j”) the ok fromDevice L for the connection and passes the location of Device L alongwith the connection matrix M1 to device R. Device R receives (“k”) theconnection information for device L. Device R connects (“l”) to M1 onthe connection matrix using M1. In the connection matrix, the presenceof a connection to both M1 and M2 opens (“m”) the connection link. Whenthis is opened device R and device L receive a handshake message thatthey can use to begin direct communications. Device R attempts to create(“n”) direct connection with device L. If this connection isestablished, then the connection matrix link is released and all devicecommunications seamlessly switch to the direct link.

In FIG. 60, a flowchart illustrating a process for the message switchingin the “Razberry” application. This is how the various subsystems in acloud are addressed. Network data received by the SwitchingCommunications box contains header information identifying the recipientof the data (see “(a)”).

Recipients could be an: (i) Inviter, which manages and processes joiningrequests for clouds on this device and accepts or rejects the requests.(ii) Joiner, which manages cloud joining requests to a cloud through thecloud contact device. (iii) Mediator, which is a relay point betweenJoiners and Inviters. (iv) Peer Communications, which manages devicechallenge messages (H) and device/cloud messages (I). (v) Look-upcommunications, which manages communications with the look-up for allclouds and also manages connection request from the look-up.

The device cloud communication contains a second header identifying thecloud device pair on this device that the message is received by (see“(b)”). The message is switched to the correct cloud.

Cloud messages contain a third header identifying their type andrecipient of the cloud message (see “(c)”). The recipient is one of: (i)The Integrity manager, where these messages are performing exchanges ofcloud state and synchronization of cloud security keys. (ii) Recordsynchronization manager, where these messages synchronize the cloudspecific records that are used to build up a single view. (iii) Queuefor Action requests, where these requests are received to performactions on objects on this device.

Further message switching is performed to target a message to aparticular object such as a file object, mail object, chat object, etc(see “(d)”). If it is a remote object the message is switched to theparticular action that was requested from the remote object (see “(e)”).

A flowchart showing an example of some steps for the maintenance ofcloud integrity is provided in FIG. 61. Cloud records that are no longeraccessed (“(a)”) are removed from memory, to reduce the memory footprintof the application. Whenever a device is not aware of any other devicesfor a cloud (“(b)”), then it attempts to look for the cloud. If thecloud is not found then the device registers with the look-up at thecloud contact point. The list of devices identifiers for a cloud is keptsynchronized (“(c)”). This is described further in FIG. 63. Wheneverdevices come on- and off-line, a determination (“(d)”) is made by eachonline device in a cloud to decide if they should become the new cloudcontact point. The lefthand integrity link is checked (“(e)”) atintervals and if the link has not been challenged after a set period oftime a new challenge is performed. If the challenge has not beenresponded to, after another set period of time, then the peer is markedas offline and not valid. All other devices on the cloud are immediatelyupdated with the offline status of this device. The righthand integritylink (“(f)”) functions the same as for (“(e)”).

A flowchart illustrating the synchronisation of peer information isprovided in FIG. 62. Similarly, a flowchart illustrating thesynchronisation of cloud information is provided in FIG. 63.

In FIG. 64, the message handling function of the lookup point isillustrated, as well as showing a possible structure of a message andmessage header that is involved in this.

In FIG. 65, the message handling function of a join query isillustrated, as well as showing a possible structure of some messagesthat are involved in this.

In FIGS. 66 to 70, various screen shots of the “Razberry” applicationare provided. FIG. 66 shows the email sub-system, which has beenselected from a list of buttons on a toolbar at the top, and shows anumber of devices containing Microsoft “Outlook” email folders gatheredtogether in a cloud. The emails for one selected device are shown inFIG. 67. FIG. 68 shows one device being selected, with the filemanagement sub-system having been selected for the device. In FIG. 69,the calendar function has been selected from the top toolbar, whichdisplays the Microsoft “Outlook” calendar data via the “Razberry”application. FIG. 70 shows one email having been opened via the“Razberry” application.

Operation Example

As an example showing the operation of the “Razberry” application, letus assume that John is looking for a file.

He starts the Razberry on his PDA and enters his user name and passwordto register with the look-up. The PDA requests the location of John'sRazberry cloud from the look-up and receives back the identifier for hishome PC.

The PDA connects to the home PC directly, and a securing verificationand state and header record synchronization occurs between the PDA andthe home PC. The PDA learns that the work PC is online and asks thelook-up for the location of the work PC. The PDA and the work PC connecttogether and now an integrity link is established between the threedevices.

John decides that he wants to view files on the work PC, and selectsthis function in the Razberry application GUI. The PDA retrieves thedevice record for the work PC and uses this to obtain the objects on thework PC. The PDA searches through the objects looking for all objectwith the object class “file”. The PDA creates a new object/actionaddressed to the file object on the work PC and the sends the actionrequest message. The work PC receives the action request message,processes the action request and sends the reply message back to thesender. The PDA receives the reply to the action request message and isable to display the list of folders on the work PC using the PDA GUI.

Examples of Razberry Functions

-   -   File Browser—allows access to files and folders (see FIG. 67)    -   Mail Browser—allows access to email content and functionality        (see FIGS. 66 & 68)    -   Calendar Browser—allows access to calendar (see FIG. 69)    -   Music Streamer—allows access to music content    -   Voice module—allows access to device microphone and speakers for        VOIP    -   Video Streamer—allows access to video content    -   Chat module—allows text messaging    -   MediaPlayer Remote—allows remote control of a devices media        player    -   Remote Application Module—allows remote application viewing and        interaction    -   Advertisement Module—has cloud user specific information and can        reach out to the web and pull in advertisements    -   Blanking Module—stores bank credentials on a safe device and        performs transactions remotely    -   Printer Module—allows access to a printer from the cloud    -   Panic Module—displays panic alerts from another device.    -   Web RSS feed module    -   FTP Server module—allows access to existing FTP servers from the        cloud    -   BLOG update module—allow updating of a BLOG from the cloud    -   Legacy module—allow access to a legacy application over the        cloud    -   Database module—allow database access over the cloud    -   Web camera module—access streaming video in the cloud

To those skilled in the art to which the invention relates, many changesin construction and widely differing embodiments and applications of theinvention will suggest themselves without departing from the scope ofthe invention as defined in the appended claims. The disclosures and thedescriptions herein are purely illustrative and are not intended to bein any sense limiting.

1. A method for sharing functionality and/or data between two or morelinked entities using a network comprising the steps of: (a) creating onat least one entity at least one real object, each said real objectproviding access to the functionality and/or data of said entity; (b)creating on each entity at least one virtual object, each said virtualobject providing access to the functionality and/or data of a realobject on said entity, each said virtual object containing at least oneobject action; and (c) creating on at least one entity at least oneremote object for connection to a virtual object on a remote entity viathe network; said remote object allowing an entity to accessfunctionality and/or data of a remote entity.
 2. A method for sharingfunctionality and/or data between two or more linked entities using anetwork as claimed in claim 1 including the step of: (d) creating on atleast one entity a metaobject, said metaobject providing access to thefunctionality and/or data of a plurality of virtual, remote and metaobjects.
 3. A method for sharing functionality and/or data between twoor more linked entities using a network as claimed in claim 2 whereinsaid metaobject can contain data and/or functionality independent of anyvirtual or remote objects.
 4. A method for sharing functionality and/ordata between two or more linked entities as claimed in claim 1 wherein alist of the objects of each entity is synchronized between entities. 5.A method for sharing functionality and/or data between two or morelinked entities as claimed in claim 3 wherein a list of the objects ofeach entity is synchronized between entities.
 6. A method for sharingfunctionality and/or data between two or more linked entities as claimedin claim 2 wherein each of said virtual and meta objects may includesecurity functionality for controlling access to the object.
 7. A methodfor sharing functionality and/or data between two or more linkedentities as claimed in claim 5 wherein each of said virtual and metaobjects may include security functionality for controlling access to theobject.
 8. A method for sharing functionality and/or data between two ormore linked entities using a network as claimed in claim 1 wherein saidnetwork is a virtual private network (VPN).
 9. A method for sharingfunctionality and/or data between two or more linked entities using anetwork as claimed in claim 7 wherein said network is a virtual privatenetwork (VPN).
 10. A method for sharing functionality and/or databetween two or more linked entities using a network as claimed in claim8 wherein said VPN consists of two or more linked entities havinginternet connectability where each entity has links with at least oneother device on the VPN, said VPN formed by the method comprising thesteps of: (a) providing a lookup device having a known address with anupdatable index of entities known to be connectable to the VPN, whichlook up device accepts requests from known entities (“joining entity”)wishing to link to the VPN, (b) causing at least one pre-designatedcontact entity on the VPN to periodically poll the lookup device forreceived joining requests, (c) said lookup device receiving a requestfrom a joining entity to connect to the VPN (d) in response to a pollfor joining requests said lookup device notifying the polling contactentity of at least the address of each joining entity, (e) if thecontact entity permits a connection to the VPN, the contact entitysupplies at least its address to the lookup device which passes this tothe joining entity, (f) the joining entity and contact entity establisha first link between them, (g) the joining entity and the contact entityconduct an authentication process over said first link, (h) and if theauthentication process is successful the contact entity notifies thejoining entity of at least the status of other entities belonging to theVPN and notifies all entities on the VPN that the joining device isjoining the VPN, (i) said joining device using the status of otherentities belonging to the VPN to calculate its node position in the VPNincluding the one or two neighbour entities it will connect to, (j) saidone or two neighbour entities initiating a process of the type specifiedin steps (c) to (f) with said lookup entity to establish one or moresecond links with said joining entity and terminating said first link,(k) and said joining entity and at least one neighbour entity conductinga mutual authentication process which if successful sustains said one ormore second links.
 11. A method for sharing functionality and/or databetween two or more linked entities using a network as claimed in claim9 wherein said VPN consists of two or more linked entities havinginternet connectability where each entity has links with at least oneother device on the VPN, said VPN formed by the method comprising thesteps of: (a) providing a lookup device having a known address with anupdatable index of entities known to be connectable to the VPN, whichlook up device accepts requests from known entities (“joining entity”)wishing to link to the VPN, (b) causing at least one pre-designatedcontact entity on the VPN to periodically poll the lookup device forreceived joining requests, (c) said lookup device receiving a requestfrom a joining entity to connect to the VPN (d) in response to a pollfor joining requests said lookup device notifying the polling contactentity of at least the address of each joining entity, (e) if thecontact entity permits a connection to the VPN, the contact entitysupplies at least its address to the lookup device which passes this tothe joining entity, (f) the joining entity and contact entity establisha first link between them, (g) the joining entity and the contact entityconduct an authentication process over said first link, (h) and if theauthentication process is successful the contact entity notifies thejoining entity of at least the status of other entities belonging to theVPN and notifies all entities on the VPN that the joining device isjoining the VPN, (i) said joining device using the status of otherentities belonging to the VPN to calculate its node position in the VPNincluding the one or two neighbour entities it will connect to, (j) saidone or two neighbour entities initiating a process of the type specifiedin steps (c) to (f) with said lookup entity to establish one or moresecond links with said joining entity and terminating said first link,(k) and said joining entity and at least one neighbour entity conductinga mutual authentication process which if successful sustains said one ormore second links.
 12. A method for sharing functionality and/or databetween two or more linked entities using a network as claimed in claim1 wherein each of said real objects are selected from the groupconsisting of File Browser, Mail Browser; Calendar Browser; MusicStreamer; Voice module; Video Streamer; Chat module; MediaPlayer Remote;Remote Application Module; Advertisement Module; Banking Module; PrinterModule; Panic Module; Web RSS feed module; FTP Server module; BLOGupdate module; Legacy module; Database module; Web camera module.
 13. Amethod for sharing functionality and/or data between two or more linkedentities using a network as claimed in claim 1 wherein at least one ofsaid entities is a device having a processor and that can be connectedto the internet.
 14. A method for sharing functionality and/or databetween two or more linked entities using a network as claimed in claim11 wherein at least one of said entities is a device having a processorand that can be connected to the internet.
 15. A method for sharingfunctionality and/or data between two or more linked entities using anetwork as claimed in claim 13 wherein said at least one said deviceincludes computers, PDAs, PPC, mobile telephones or smartphones, andembedded devices.
 16. A method for sharing functionality and/or databetween two or more linked entities using a network as claimed in claim14 wherein said at least one said device includes computers, PDAs, PPC,mobile telephones or smartphones, and embedded devices.
 17. Computersoftware for sharing functionality and/or data between two or morelinked entities using a network, said software residing on each saidentity and comprising: (a) a routine for creating at least one realobject, each said real object providing access to the functionalityand/or data of said entity; (b) a routine for creating at least onevirtual object, each of said of virtual objects providing access to thefunctionality and/or data of a real object on said entity, each saidvirtual object containing at least one object actions; and (c) a routinefor creating at least one remote object for connection to a virtualobject on a remote entity via the network; said remote object allowingan entity to access functionality and/or data of a remote entity. 18.One or more computer-readable media comprising computer-readablesoftware as claimed in claim
 17. 19. An electromagnetic signal carryingcomputer-readable software as claimed in claim 17.